Repository navigation
petri: make Windows image preparation independent of disk discovery order - #5068
Maheer Aeron (maheeraeron) wants to merge 1 commit into
Conversation
|
This PR modifies files containing For more on why we check whole files, instead of just diffs, check out the Rustonomicon |
69b022a to
25604cd
Compare
There was a problem hiding this comment.
🟢 Approval recommended
There are no active review issues for the Windows image-preparation changes.
No open issues 🎉
What changed in this PR
Makes Petri’s Windows image preparation independent of disk discovery order, preventing accidental target boots and ensuring preparation modifies the intended Windows volume.
Changes:
- Assigns the Windows agent partition a stable GUID and reserves
D:through the IMC hive. - Boots the source image before attaching the target, then discovers the target Windows volume by GPT disk GUID.
- Uses the discovered drive for offline updates and copies the agent’s mount mapping into the prepared image.
| File | Description |
|---|---|
vmm_tests/prep_steps/src/main.rs |
Delays target attachment, discovers its drive, and updates offline preparation paths and mount mappings. |
vmm_tests/prep_steps/Cargo.toml |
Adds Mesh support for disk attachment requests. |
petri/src/vm/hyperv/mod.rs |
Keeps crash-disk partition GUID generation unchanged with the updated helper. |
petri/src/disk_image.rs |
Supports explicit partition GUIDs and uses the stable identity for Windows agent disks. |
petri/petri_artifacts_common/src/windows_agent.rs |
Defines the shared Windows agent partition GUID. |
petri/petri_artifacts_common/src/lib.rs |
Exposes the Windows agent identity module. |
petri/petri_artifacts_common/Cargo.toml |
Adds the GUID dependency. |
petri/make_imc_hive/src/windows/offreg.rs |
Adds binary registry-value writing support. |
petri/make_imc_hive/src/windows/mod.rs |
Maps the agent partition to D: in the IMC hive. |
petri/make_imc_hive/Cargo.toml |
Adds access to the shared agent partition identity. |
Cargo.lock |
Records the updated workspace dependencies. |
Review effort: Balanced
25604cd to
3243126
Compare
There was a problem hiding this comment.
🟡 Changes recommended
Hard-coded E: paths can cause preparation to time out for targets mounted elsewhere, and the missing persistent D: mapping leaves subsequent pipette startup dependent on drive-letter assignment.
2 open issues
Review effort: Balanced
Steven Malis (smalis-msft)
left a comment
There was a problem hiding this comment.
Did this happen at some point?
Looks like this happened? But never again: |
|
I feel like there is probably a better way to do this, but if this works (which it seems to) I'm ok with this for now since it is a relatively simple change. |

Boot the preparation VM and wait for pipette before hot-attaching the target disk. This prevents firmware from booting the target and avoids it competing with the agent disk for drive letters during initial boot.
Wait up to 30 seconds for the target Windows volume at E: before preparing it. Existing drive-letter assumptions remain unchanged. Validated with fresh prep and a passing no-VMBus boot test using previously problematic Patina firmware.